Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle bot launch error so the app won't crash #1146

Closed
wants to merge 1 commit into from

Conversation

mfahmialkautsar
Copy link

I am always annoyed when my app is deployed to Vercel which is serverless (so the app must be started at every function call), there's always a chance for the nestjs-telegraf to throw error API call when launching, such as:

2023-09-27T05:49:41.056Z 1c417191-68c4-4c4a-bcb5-55210c2e2845 ERROR Unhandled Promise Rejection {"errorType":"Runtime.UnhandledPromiseRejection","errorMessage":"Error: 429: Too Many Requests: retry after 1","reason":{"errorType":"Error","errorMessage":"429: Too Many Requests: retry after 1","code":429,"response":{"ok":false,"error_code":429,"description":"Too Many Requests: retry after 1","parameters":{"retry_after":1}},"on":{"method":"setWebhook","payload":{"url":"https://myapp-a3kd7o5r5-myusername.vercel.app/my-secret-path"}},"stack":["Error: 429: Too Many Requests: retry after 1"," at Telegram.callApi (/var/task/node_modules/.pnpm/telegraf@4.14.0/node_modules/telegraf/lib/core/network/client.js:294:19)"," at processTicksAndRejections (node:internal/process/task_queues:95:5)"," at Telegraf.launch (/var/task/node_modules/.pnpm/telegraf@4.14.0/node_modules/telegraf/lib/telegraf.js:198:9)"]},"promise":{},"stack":["Runtime.UnhandledPromiseRejection: Error: 429: Too Many Requests: retry after 1"," at process.<anonymous> (file:///var/runtime/index.mjs:1250:17)"," at process.emit (node:events:526:35)"," at process.emit (/var/task/___vc/__sourcemap_support.js:602:21)"," at emit (node:internal/process/promises:149:20)"," at processPromiseRejections (node:internal/process/promises:283:27)"," at processTicksAndRejections (node:internal/process/task_queues:96:32)"]} [ERROR] [1695793781058] LAMBDA_RUNTIME Failed to post handler success response. Http response code: 400. RequestId: 7b50cdab-42c0-42ee-b707-e2392b984d1b Error: Runtime exited with error: exit status 128 Runtime.ExitError

So I think it would be better to ignore the error and let the app run without nestjs-telegraf module. Because it's just a webhook and if my app has another API that's called from other client, it won't need the Telegram webhook. In serverless case, it wouldn't matter for Telegram webhook since it will retry to call the endpoint again.

@vercel
Copy link

vercel bot commented Sep 27, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
nestjs-telegraf ✅ Ready (Inspect) Visit Preview 💬 Add feedback Sep 27, 2023 0:11am
nestjs-telegraf-api ✅ Ready (Inspect) Visit Preview 💬 Add feedback Sep 27, 2023 0:11am

@bebop23
Copy link

bebop23 commented Aug 20, 2024

Any prescribed approach on how to avoid this error? My app is also facing this issue when starting up cloudrun instances in GCP where multiple instances are being spawned around the same time which causes the 429s when setting the webhook.

@mfahmialkautsar
Copy link
Author

Any prescribed approach on how to avoid this error? My app is also facing this issue when starting up cloudrun instances in GCP where multiple instances are being spawned around the same time which causes the 429s when setting the webhook.

This issue happens because the Telegram webhook API is called every time the app starts, which is not suitable for serverless environments.

I previously suggested a change to handle this by ignoring the error and allowing the app to continue running, assuming the webhook might have already been set in a previous call. Since the maintainers didn't accept the PR, I forked the repo and made the change myself. You can use my fork by replacing the source to be "nestjs-telegraf": "github:mfahmialkautsar/nestjs-telegraf#dist" in your package.json.

Note that I haven't updated the fork since then, and it's more of a temporary workaround. Ideally, I think the best approach would be to create a dedicated API endpoint for registering the webhook, which you can call manually when needed. This way, the webhook setup doesn't happen on every app start, making it very efficient and reducing the chance of hitting rate limits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants